…, r=scottmcm

reference type safety invariant docs: clarification

The old text could have been read as saying that you can call a function if these requirements are upheld, which is definitely not true as they are an underapproximation of the actual safety invariant.

I removed the part about functions relaxing the requirements via their documentation... this seems incoherent with saying that it may actually be unsound to ever temporarily violate the requirement. Furthermore, a function *cannot* just relax this for its return value, that would in general be unsound. And the part about "unsafe code in a safe function may assume these invariants are ensured of arguments passed by the caller" also interacts with relaxing things: clearly, if the invariant has been relaxed, unsafe code cannot rely on it any more. There may be a place to give general guidance on what kinds of function contracts can exist, but the reference type is definitely not the right place to write that down.

I also took a clarification from rust-lang#121965 that is orthogonal to the rest of that PR.

Cc `@joshlf` `@scottmcm`

…iaskrgr

Rollup of 7 pull requests

Successful merges:

 - rust-lang#124227 (Make sure that the method resolution matches in `note_source_of_type_mismatch_constraint`)
 - rust-lang#124896 (miri: rename intrinsic_fallback_checks_ub to intrinsic_fallback_is_spec)
 - rust-lang#125015 (Pattern types: Prohibit generic args on const params)
 - rust-lang#125043 (reference type safety invariant docs: clarification)
 - rust-lang#125259 (An async closure may implement `FnMut`/`Fn` if it has no self-borrows)
 - rust-lang#125306 (Force the inner coroutine of an async closure to `move` if the outer closure is `move` and `FnOnce`)
 - rust-lang#125378 (remove tracing tree indent lines)

r? `@ghost`
`@rustbot` modify labels: rollup

…, r=scottmcm

reference type safety invariant docs: clarification

The old text could have been read as saying that you can call a function if these requirements are upheld, which is definitely not true as they are an underapproximation of the actual safety invariant.

I removed the part about functions relaxing the requirements via their documentation... this seems incoherent with saying that it may actually be unsound to ever temporarily violate the requirement. Furthermore, a function *cannot* just relax this for its return value, that would in general be unsound. And the part about "unsafe code in a safe function may assume these invariants are ensured of arguments passed by the caller" also interacts with relaxing things: clearly, if the invariant has been relaxed, unsafe code cannot rely on it any more. There may be a place to give general guidance on what kinds of function contracts can exist, but the reference type is definitely not the right place to write that down.

I also took a clarification from rust-lang#121965 that is orthogonal to the rest of that PR.

Cc ``@joshlf`` ``@scottmcm``

Rollup of 7 pull requests

Successful merges:

 - rust-lang#125043 (reference type safety invariant docs: clarification)
 - rust-lang#125306 (Force the inner coroutine of an async closure to `move` if the outer closure is `move` and `FnOnce`)
 - rust-lang#125355 (Use Backtrace::force_capture instead of Backtrace::capture in rustc_log)
 - rust-lang#125378 (remove tracing tree indent lines)
 - rust-lang#125391 (Minor serialize/span tweaks)
 - rust-lang#125395 (Remove unnecessary `.md` from the documentation sidebar)
 - rust-lang#125399 (Stop using `to_hir_binop` in codegen)

r? `@ghost`
`@rustbot` modify labels: rollup

Rollup of 7 pull requests

Successful merges:

 - rust-lang#125043 (reference type safety invariant docs: clarification)
 - rust-lang#125306 (Force the inner coroutine of an async closure to `move` if the outer closure is `move` and `FnOnce`)
 - rust-lang#125355 (Use Backtrace::force_capture instead of Backtrace::capture in rustc_log)
 - rust-lang#125382 (rustdoc: rename `issue-\d+.rs` tests to have meaningful names (part 7))
 - rust-lang#125391 (Minor serialize/span tweaks)
 - rust-lang#125395 (Remove unnecessary `.md` from the documentation sidebar)
 - rust-lang#125399 (Stop using `to_hir_binop` in codegen)

r? `@ghost`
`@rustbot` modify labels: rollup

Rollup of 7 pull requests

Successful merges:

 - rust-lang#125043 (reference type safety invariant docs: clarification)
 - rust-lang#125306 (Force the inner coroutine of an async closure to `move` if the outer closure is `move` and `FnOnce`)
 - rust-lang#125355 (Use Backtrace::force_capture instead of Backtrace::capture in rustc_log)
 - rust-lang#125382 (rustdoc: rename `issue-\d+.rs` tests to have meaningful names (part 7))
 - rust-lang#125391 (Minor serialize/span tweaks)
 - rust-lang#125395 (Remove unnecessary `.md` from the documentation sidebar)
 - rust-lang#125399 (Stop using `to_hir_binop` in codegen)

r? `@ghost`
`@rustbot` modify labels: rollup

Rollup merge of rust-lang#125043 - RalfJung:ref-type-safety-invariant, r=scottmcm

reference type safety invariant docs: clarification

The old text could have been read as saying that you can call a function if these requirements are upheld, which is definitely not true as they are an underapproximation of the actual safety invariant.

I removed the part about functions relaxing the requirements via their documentation... this seems incoherent with saying that it may actually be unsound to ever temporarily violate the requirement. Furthermore, a function *cannot* just relax this for its return value, that would in general be unsound. And the part about "unsafe code in a safe function may assume these invariants are ensured of arguments passed by the caller" also interacts with relaxing things: clearly, if the invariant has been relaxed, unsafe code cannot rely on it any more. There may be a place to give general guidance on what kinds of function contracts can exist, but the reference type is definitely not the right place to write that down.

I also took a clarification from rust-lang#121965 that is orthogonal to the rest of that PR.

Cc ```@joshlf``` ```@scottmcm```